The invention relates generally to software applications and, more particularly, to methods and apparatus for aborting threads in an object-based system.
Within an object-based environment, threads are often used to satisfy requests for services. A thread may be thought of as a xe2x80x9csketch padxe2x80x9d of storage resources, and is essentially a single sequential flow of control within a computer program. In general, a thread, or a xe2x80x9cthread of control,xe2x80x9d is a sequence of central processing unit (CPU) instructions or programming language statements that may be independently executed. Each thread has its own execution stack on which method activations reside. As will be appreciated by those skilled in the art, when a method is activated with respect to a thread, an activation is xe2x80x9cpushedxe2x80x9d on the execution stack of the thread. When the method is deactivated, the activation is xe2x80x9cpoppedxe2x80x9d from the execution stack. Since an activation of one method may activate another method, an execution stack operates in a first-in-last-out manner.
Although threads generally self terminate, one may also wish to forcefully terminate a thread while it is executing. For example, one may wish to terminate a thread whose currently executing code is currently mounting a xe2x80x9cdenial of service attack.xe2x80x9d A denial of service attack uses all or most of the local host""s resources (e.g., processor and/or memory resources). For example, code associated with a particular thread may initiate an infinite loop, which functions to open an infinite number of windows. In this example, the code continues to open windows until so many resources are consumed that the particular application that is executing the code (or the entire computer system) crashes or freezes up.
A denial of service attack is generally associated with untrusted code that originates from an unknown source. For example, downloaded computer programs may include methods from an unknown programming source. In other words, the downloaded program may include untrusted code that was maliciously or unintentionally designed to mount a denial of service attack.
Thus, when code begins to misbehave (e.g., by using an unreasonable amount of resources), it is desirable to kill the thread that is associated with this misbehaving code. One potential solution that has been contemplated is xe2x80x9cthread.destroyxe2x80x9d, which is currently available as a resource within the Java(trademark) II Standard Development Kit although it has not been implemented. Thread.destroy works by deallocating the stack associated with the misbehaving thread. In- other words, the thread""s stack is removed from the scheduler, which schedules threads for execution.
Although this solution may work in some situations, thread.destroy does not clean up the internal data structures that the misbehaving thread may have inconsistently altered. That is, the misbehaving thread may be writing to an internal data structure when it is killed and may only partially fill the internal data structure. For example, the misbehaving thread may initiate a print function by setting a print flag, but not yet write to the print buffer before the misbehaving thread is killed. In this example, a thread.destroy may cause garbage to be printed since the thread was killed before it could write valid print data to the print buffer.
Another solution xe2x80x9cthread.stopxe2x80x9d is currently available as a resource within the Java(trademark) II Standard Development Kit. Thread.stop throws an exception so that a currently executing method may xe2x80x9ccatchxe2x80x9d the exception and execute any implemented clean up code. Although trusted code is generally designed to perform clean up routines (e.g., within a xe2x80x9cfinallyxe2x80x9d block), untrusted code cannot be trusted to perform such clean up processes. In other words, the untrusted code""s may continue to misbehave when an exception is thrown. For example, when an exception is thrown, an untrusted code""s xe2x80x9cfinallyxe2x80x9d routine may also mount a denial of service attack. Additionally, thread.stop does not provide any mechanisms for cleaning up any inconsistent data structures.
Therefore, improved methods and apparatus for killing threads associated with code that is misbehaving are desired. Additionally, there is a desire to cleanly kill these threads such that data structures are left in a consistent state.
Broadly speaking, the present invention fills these needs by providing apparatus and methods for aborting threads. In one aspect of the invention, the frames of a thread stack that are associated with the misbehaving code are popped from the thread stack. Exception handling code is allowed to execute for trusted code by popping the trusted code frame via processing an exception, but exception handling is not allowed to execute for untrusted code. In a second aspect, frames are popped on all thread stacks of all threads that are associated with the misbehaving code. Threads are generally deemed to be associated with the misbehaving code when the threads share a same object or the same resources as the thread that is associated with the misbehaving code.
In one embodiment, the invention pertains to a method for aborting a thread that has an associated thread stack with a plurality of frames that are associated with either trusted or untrusted code. A frame within the thread stack of the thread to be aborted is selected. The selected frame from the thread stack of the thread to be aborted is popped when the selected frame is associated with untrusted code. An exception is thrown for the selected frame from the thread stack of the thread to be aborted when the selected frame is associated with trusted code.
In a preferred embodiment, the above described method is repeated for each frame within the thread stack such that the associated thread is aborted. In one aspect, the trusted code is unlikely to result in a denial of service attack and it is unknown whether untrusted code will mount a denial of service attack. In another aspect, the untrusted code has an unknown resource utilization amount. In yet another aspect, the untrusted code was downloaded from an untrusted source. In a final embodiment, processing an exception for the selected frame allows the selected frame to complete any clean up routines.
In yet another embodiment, the invention pertains to a computer readable medium containing instructions for aborting a thread that has an associated thread stack with a plurality of frames that are associated with either trusted or untrusted code. The computer readable medium includes (a) computer code for selecting a frame within the thread stack of the thread to be aborted, (b) computer code for popping the selected frame from the thread stack of the thread to be aborted when the selected frame is associated with untrusted code, and (c) computer code for processing an exception for the selected frame from the thread stack of the thread to be aborted when the selected frame is associated with trusted code.
In another aspect, the invention pertains to a computer system for aborting a thread that has an associated thread stack with a plurality of frames that are associated with either trusted or untrusted code. The computer system includes an identifier configured to select a frame within the thread stack of the thread to be aborted and a frame handler configured to pop the selected frame from the thread stack of the thread to be aborted when the selected frame is associated with untrusted code and to process an exception for the selected frame from the thread stack of the thread to be aborted when the selected frame is associated with trusted code.
In an alternative embodiment, a method for aborting one or more threads is disclosed. Each thread executes one or more code sets, wherein at least one of the code sets has been identified as misbehaving and is associated with an abort identifier. At least one of the code sets include one or more checkpoints. The abort identifier of the misbehaving code is set to indicate that an abort procedure is to be performed. Currently executing threads that have code sets that are associated with the abort identifier abort are aborted.
In one alternative embodiment, the currently executing threads that are associated with the abort identifier are aborted by processing an exception for the currently executing code set when an abort checkpoint has been reached and the currently executing code set is associated with the abort identifier associated with the misbehaving code set. If there is no abort checkpoint, execution of the code set associated with the currently executed thread is continued.
In another embodiment, currently executing threads that are associated with the abort identifier further are aborted by determining whether there is an abort checkpoint located prior to the exception handling code when the currently executing code set contains exception handling code. The exception handling code is inhibited from executing when the currently executing code set contains exception handling code and if there is an abort checkpoint located prior to the exception handling code. In a preferred embodiment, the exception handling code is inhibited only if the exception handling code is associated with the abort identifier associated with the misbehaving code set.
In another aspect, the invention pertains to a computer readable medium containing instructions for aborting one or more threads. Each thread executes one or more code sets. At least one of the code sets has been identified as misbehaving and is associated with an abort identifier, and at least one of the code sets have one or more checkpoint inserted within the code set. The computer readable medium includes computer code for setting the abort identifier of the misbehaving code to indicate that an abort procedure is to be performed and computer code for aborting currently executing threads that have code sets that are associated with the abort identifier.
In another embodiment, the invention pertains to a computer system configured to abort one or more threads. Each thread executes one or more code sets, and at least one of the code sets has been identified as misbehaving and is associated with an abort identifier. At least one of the code sets have one or more checkpoint inserted within the code set. The computer system includes an abort indicator arranged to set the abort identifier of the misbehaving code to indicate that an abort procedure is to be performed and a thread executioner arranged to abort currently executing threads that have code sets that are associated with the abort identifier.
The described embodiments of the present invention have several associated advantages. For example, when a method frame is popped that is associated with misbehaving code, exception handling is inhibited if the popped frame is associated with untrusted code. Thus, untrusted code is inhibited from continuing to misbehave through its exception handling code. In contrast, trusted code is allowed to perform exception handling (e.g., clean up routines) prior to aborting the associated thread. Thus, the likelihood of internal data structures being left in an inconsistent state is minimized. Additionally, in one embodiment, all of the threads that share a same resource are aborted. Thus, if the shared resource is left in an inconsistent state by an aborted thread, other threads that are associated with the inconsistent shared resource are prohibited from accessing the inconsistent resource when they too are aborted.
These and other advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings.